update elicitation mechanism to allow for elicitations outside of the…#792
update elicitation mechanism to allow for elicitations outside of the…#792
Conversation
|
@anna239 could you share a bit the behind the scenes conversations to understand the decision making around it? |
| pub session_id: Option<SessionId>, | ||
| /// Optional request ID if this elicitation is tied to a specific request. | ||
| #[serde(skip_serializing_if = "Option::is_none")] | ||
| pub request_id: Option<RequestId>, |
There was a problem hiding this comment.
Do we want to require one or the other? I can help turn this into an enum to express that you have to have one (and not non or both?)
There was a problem hiding this comment.
I'm not sure, I think there are valid use cases for none option — like you can have a request that is not tied to a particular session or to the json rpc request, the agent can just ask you to provide some additional settings f.i. before any session is started.
Providing both might be ambiguous (in case you can tide requestId to a session already).
But maybe I'm overthinking and we should go with either-or
|
@yordis it's clear that there are use-cases for other methods that this can be helpful. The idea is to have it either for a session or some other request, and then the client would need to have some way to express general elicitations, for the auth/configuration phases to be concrete |
Related to #376 (comment) @benbrandt that was a precise question in the RFD, and the idea was that such workflow didn't belong to the Elicitation per se, which it is fine, I do not have strong opinions, but overlapping concepts may arise. Documenting the decision making would be amazing, so we all have a trail history of the "why" behind it. Sometimes isn't obvious what the motivation is, so it helps to share the intent. |
|
Sure thing. before we merge this we would need to update the RFD which is where we'd capture that |
3 participants
… session scope